WCAG Official Guidelines (W3C)

WCAG is the global accessibility standard.

Current widely adopted version:

WCAG 2.2 (many organisations still validate against 2.1 AA minimum)

WCAG is built around four principles:

POUR

P — Perceivable

Users must be able to perceive content.

Examples:

✓ Images have alt text
✓ Sufficient colour contrast
✓ Videos have captions

Bad:

<img src="checkout-button.png">

Good:

<img
 src="checkout-button.png"
 alt="Checkout">

O — Operable

Users must be able to operate controls.

Examples:

✓ Keyboard accessible
✓ No keyboard traps
✓ Sufficient click targets

Bad:

Mouse-only dropdown.

Good:

Mouse + keyboard support.

U — Understandable

Content and behaviour must be understandable.

Examples:

✓ Clear labels
✓ Consistent navigation
✓ Helpful error messages

Bad:

Error 4502

Good:

Password must contain 8 characters

R — Robust

Content works across:

• Browsers
• Assistive technologies
• Future technologies

Examples:

✓ Semantic HTML
✓ Proper ARIA usage
✓ Valid markup

2. WCAG Conformance Levels

A

Minimum accessibility.

AA

Industry standard.

Most organisations target:

WCAG 2.2 AA

AAA

Highest level.

Not always practical.

Example:

Colour contrast:

AA:

4.5:1

AAA:

7:1

3. Keyboard Navigation Testing

Many users cannot use a mouse.

QA must validate keyboard-only usage.

Primary keys:

TAB
SHIFT + TAB
ENTER
SPACE
ESC
ARROW KEYS
HOME
END

Keyboard Checklist

Navigate entire page using keyboard only.

Validate:

✓ All controls reachable

✓ Logical tab order

✓ Visible focus indicator

✓ Dropdown works

✓ Modal works

✓ Escape closes modal

✓ Keyboard not trapped

Example failure:

Tab -> Search
Tab -> Basket
Tab -> Footer

Checkout button skipped

FAIL.

Example modal validation:

Open modal.

Expected:

TAB
↓
Focus remains inside modal
↓
ESC closes modal
↓
Focus returns to trigger

Common defect:

Focus disappears behind modal.

4. Focus Management

Focus management is one of the biggest accessibility failures.

Focus = where keyboard interaction currently exists.

Example:

<button>
Checkout
</button>

When tabbing:

Expected:

Visible focus.

Good:

button:focus {
 outline:3px solid blue;
}

Bad:

outline:none;

Never remove focus without replacement.

Focus Order

Expected:

Logo
↓
Search
↓
Navigation
↓
Product Grid
↓
Basket

Bad:

Search
↓
Footer
↓
Navigation
↓
Basket

Confusing.

Dynamic Content Focus

Example:

User clicks:

Open Filters

Expected:

Focus moves:

Filter Panel

Common defect:

Panel opens visually.

Keyboard remains behind panel.

5. Screen Reader Testing

Screen readers convert content into spoken output.

Popular screen readers:

Windows

• NVDA (free)
• JAWS

Apple

• VoiceOver

Android

• TalkBack

QA commonly validates:

NVDA + Chrome

VoiceOver + Safari

Example page:

<button>
Submit
</button>

Screen reader:

Submit button

Good.

Bad:

<button></button>

Screen reader:

Button

User does not understand purpose.

Example image:

Bad:

<img src="sale.jpg">

Screen reader:

Graphic

Good:

<img
 src="sale.jpg"
 alt="50 percent off summer sale">

6. ARIA (Accessible Rich Internet Applications)

ARIA improves accessibility for dynamic interfaces.

Important rule:

Use native HTML first.

Good:

<button>
Save
</button>

Bad:

<div role="button">
Save
</div>

Only use ARIA when native HTML cannot solve it.

Common ARIA attributes:

aria-label

Provides accessible name.

Bad:

<button>
🔍
</button>

Good:

<button
 aria-label="Search">
🔍
</button>

aria-expanded

Dropdown state.

<button
 aria-expanded="false">
Menu
</button>

Open:

<button
 aria-expanded="true">
Menu
</button>

Screen reader announces state.

aria-live

Announces dynamic changes.

Example basket update:

<div
aria-live="polite">
Basket updated
</div>

Screen reader:

Basket updated

Without ARIA:

Silent.

aria-describedby

Links help text.

<input
aria-describedby="password-help">

<div id="password-help">
Minimum 8 characters
</div>

7. Colour Contrast Testing

Users with visual impairments need readable contrast.

WCAG AA:

Normal text:

4.5:1

Large text:

3:1

UI components:

3:1

Example FAIL:

Light grey text:

#AAAAAA

Background:

#FFFFFF

Poor readability.

Tools:

Colour Contrast Checker

WebAIM Contrast Checker

Browser DevTools

Chrome Lighthouse accessibility audit.

Never rely on colour alone.

Bad:

Red field = error

Good:

❌ Error icon
Error text
Red border

8. Accessibility QA Checklist

Images

✓ Alt text present

✓ Decorative images hidden

Forms

✓ Labels associated

✓ Errors announced

✓ Required fields identified

Keyboard

✓ Full keyboard support

✓ Visible focus

✓ No keyboard traps

Screen Readers

✓ Buttons announced correctly

✓ Links descriptive

✓ Dynamic updates announced

Colour

✓ Contrast compliant

✓ Colour not only indicator

Structure

✓ Heading hierarchy logical

Good:

H1
 H2
  H3

Bad:

H1
 H4
 H2

9. Accessibility Testing Tools QA Teams Use

Automated:

axe DevTools

axe DevTools

Finds:

• Missing labels
• ARIA issues
• Contrast failures

Lighthouse

Built into Chrome.

Checks:

• Contrast
• Labels
• Semantic HTML

WAVE

WAVE Accessibility Tool

Visual accessibility issues.

Manual Testing (Critical)

Automation finds ~30–50%.

Human testing finds:

• Keyboard issues
• Screen reader usability
• Focus problems
• Content understanding

Manual testing is essential.

10. Real-world QA a11y example (Checkout page)

Validate:

Keyboard:

TAB entire checkout

Focus:

Visible everywhere

Screen reader:

Basket total announced

Forms:

Errors announced

Colour:

Contrast passes

Payment modal:

Focus trapped
ESC works

Dynamic basket updates:

aria-live announcements

11. Senior QA accessibility mindset

Junior QA:

"Page works."

Strong QA:

"Can a keyboard-only user complete checkout? Can a screen reader user understand errors? Can low-vision users read content? Does focus behave correctly after dynamic changes?"

That mindset separates accessibility-aware QA from standard functional QA.

Next logical topic: Accessibility automation (axe-core + Playwright/Cypress/Selenium integration, automated WCAG validation, CI/CD accessibility gates).